\section{Product Lines in the Automotive Industry}
\label{sec:bg:spl}

\subsubsection{Product Lines in GM.}
Modern cars at GM can contain tens of millions of lines of code,
encompassing powertrain control, active and passive safety features, climate
control, comfort and convenience systems, security systems, entertainment
systems, and middleware to interconnect all of the above. In addition to
software complexity, the variability is high -- over 60 models with further
variation to account for requirements differences in 150+ countries. The number
of product variants produced is in the low tens of thousands. GM is
re-engineering its variability tooling to use the commercial product line
tool Gears by BigLever
Software\footnote{\url{www.biglever.com}}~\cite{flores13}. 
%Gears uses an
%annotative product line approach that can be mapped into the approach described
%in Sec.~\ref{sec:prodline}. 
To help manage the complexity, product lines will
be decomposed into modules corresponding to the natural divisions in the
automotive system architecture to produce a hierarchical product line. For
example, the subsystems dealing with entertainment, climate control, etc. will
have their own product lines, and these will be merged into parent product lines
to represent the variability for an entire vehicle. 

% \rs{TODO:}
% \noindent
% How does the product line of GM models look like, based on input from Ramesh.\\
% ---			how many features (order of hundreds) \\
% ---			how many variation points (order of tens of hundreds)\\
% ---			size of each product (for requirements: 4-5 pairs of pre-post
% conditions)\\
% --- 		complexity of presence conditions \\
% ---			a little bit about the metamodel?
% \vspace{0.2in}
% 
% \noindent
  
  
\subsubsection{Case Study Product Line.}
\label{s:exemplar}
We applied a transformation on a realistic product line exemplar (as opposed
to the actual product line used in GM) due to reasons of confidentiality. 
We started with publicly available models~\cite{simulinkEGS}
and built an exemplar model conforming to the GM metamodel in Fig.~\ref{fig:gmMMfig}
and consisting of six features and 201 elements.
 With the help of our industrial partners, we validated
that our exemplar is realistic in terms of its structure and size.
Since our goal is to do transformation lifting, the product line
we produced is \emph{annotative}~\cite{Czarnecki:Antkiewicz:2005,Kastner:Apel:2008,rubin12}.
We formally review the definition of the annotative product line approach below.

\BD[Product Line]
\label{def:pl}
 A product line $P$ consists of the following parts:\\
 (1)   A \emph{feature model} that consists of a set of features and the
 constraints between them; 
 %$\Phi$ evaluates to true iff a given feature combinations is valid.
 (2) a \emph{domain model} consisting of a set of model elements; and, 
 (3) a mapping from the feature model to the domain model that assigns to 
 each element of the domain model a propositional formula called its \emph{presence    
 condition} expressed in terms of features. 
 We call any selection of features that satisfy the constraints in the feature model to be a \emph{configuration} and the 
 corresponding set of domain elements with presence conditions that evaluate to $True$ given these features is called a \emph{product}. We denote the set of all configurations of $P$ by
 $\mathsf{Conf}(P)$.
%  A product line $P$ consists of the following parts:\\
% (1)   A \emph{feature model} that consists of a set of features and a
% propositional formula $\Phi_P$ defined over these features to specify the
% relationships between them. 
% %$\Phi$ evaluates to true iff a given feature combinations is valid.
% (2) A \emph{domain model} consisting of a set of model elements.
% (3) A \emph{mapping} from the feature model to the domain model consisting of
% pairs $\langle \mathtt{E}, \phi_{\mathtt{E}} \rangle$ mapping a domain model
% element $\mathtt{E}$ to a propositional formula $\phi_{\mathtt{E}}$ over
% features. The formula $\phi_{\mathtt{E}}$ is referred to as the \emph{presence
% condition} of the element $\mathtt{E}$.  
%
 \ED


% For example, ``variation points'' correspond to places in the domain model
% where there is variability using features and these have propositional
% conditions corresponding to presence conditions, etc. 
%capture the notion of features, ``mapping'' similarWe transformed GM-style
%Gears product lines to annotative product lines. \mc{Explain} \\

% \begin{figure}[t]
% \begin{center}
% \includegraphics[width=0.8\textwidth]{imgs/ToyExample4PaperFinal.pdf}
% \includegraphics[width=0.18\textwidth]{imgs/featureModel.pdf}
% \caption{A fragment of the exemplar automotive product line model. The left side shows the
% domain model annotated with presence conditions and the right side shows the feature model.}
% \label{fig:toyexample}
% \end{center}
% \end{figure}

\begin{figure}[t]
\begin{center}
\includegraphics[width=\textwidth]{imgs/toyExample.pdf}
\caption{A fragment of the exemplar automotive product line model. The left side shows the
domain model annotated with presence conditions and the right side shows the feature model.}
\label{fig:toyexample}
\end{center}
\end{figure}
   
Note that the Gears product lines used at GM are annotative but use a slightly
different terminology than in Def.~\ref{def:pl}.
Fig.~\ref{fig:toyexample} shows a fragment of the exemplar product line to
illustrate the components of an annotative product line.  It shows
three of the six features: feature \emph{F2} representing Adaptive Cruise Control (ACC),
\emph{F8} representing Anti-lock Braking System (ABS), and \emph{F3} representing 
% \mf{Added:}
 Smart Control (SC), an integrated system for assisted driving. 
% \rs{Great. Why don't we use the acronyms ABS, ACC and SC instead of F2, F3 and
% F8?} 
% \mf{Good point, but Gehan has no time, and I need to focus on other parts of the
% paper. If I don't get around to it now, let's fix that in camera ready.}
The relevant fragment of the feature model is shown on the right of the
figure and the solid bar connecting the three features expresses the constraint that the features are mutually exclusive.

The domain model is a class diagram showing the architectural elements. 
The \emph{BodyControl PhysicalNode} runs
\emph{Partitions} such as the \emph{HumanMachineInterface}. The
\emph{HumanMachineInterface Partition} contains the \emph{Display Module} which
runs multiple \emph{ExecFrames} at the same or different rates. The
\emph{De\_ActivateACC} ExecFrame allows controlling the ACC feature by invoking
Services for variable updates (e.g., \emph{TurnACCon} and \emph{TurnACCoff
Services}). The \emph{BrakingControl PhysicalNode}
runs the \emph{SituationManagement Partition}. The
\emph{SituationManagement Partition} contains the \emph{ABScontroller Module}
which runs the \emph{De\_activateABS ExecFrame}. The \emph{De\_activateABS
ExecFrame} provides the \emph{TurnABSoff} and \emph {SetABSstate} Services to
control the ABS feature. 
%The ACC and ABS feature (F3) spans the elements and
%associations that are part of F2 and F8. Moreover in F3, 
The \emph{De\_activateABS ExecFrame} provides a \emph{Service} (i.e.,
\emph{TurnABSoff}) that is required by the \emph{De\_ActivateACC ExecFrame}, and
the two \emph{ExecFrames} require a common \emph{Service} (i.e.,
\emph{TurnACCoff}).
% \mf{Added:}
% Finally, SC requires using all the domain elements, as well as elements outside
% the scope of this fragment. 
% \rs{Actually, I removed the text that says what features cover what elements
% because I just wanted to focus on the domain model here. The presence condition
% discussion is in the next para.}

The presence conditions mapping the features to the elements of the domain model are
shown directly annotating the architecture elements. For example, the element
\emph{BodyControl} has the presence condition \emph{F2 or F3}. Configuring the product line
to produce a particular product involves selecting the features that 
should be in the product and then using these features with the presence 
conditions to extract the domain elements that should be in the product. 
For example, assume that we want to configure the product that has only feature
\emph{F2}.  In this case, the product will contain the element
\emph{BodyControl} because its presence condition says that it is present when the
product contains feature \emph{F2} or if it contains \emph{F3}. However, it will
not contain element \emph{SetABState} because its presence condition is \emph{F8
or F3}.


%The ACC feature (F2) spans the \emph{BodyControl PhysicalNode} which runs
%\emph{Partitions} such as the \emph{HumanMachineInterface}. The
%\emph{HumanMachineInterface Partition} contains the \emph{Display Module} which
%runs multiple \emph{ExecFrames} at the same or different rates. The
%\emph{De\_ActivateACC} ExecFrame allows controlling the ACC feature by invoking
%Services for variable updates (e.g., \emph{TurnACCon} and \emph{TurnACCoff
%Services}). The ABS feature (F8) spans the \emph{BrakingControl PhysicalNode}
%which runs the \emph{SituationManagement Partition}. The
%\emph{SituationManagement Partition} contains the \emph{ABScontroller Module}
%which runs the \emph{De\_activateABS ExecFrame}. The \emph{De\_activateABS
%ExecFrame} provides the \emph{TurnABSoff} and \emph {SetABSstate} Services to
%control the ABS feature. The ACC and ABS feature (F3) spans the elements and
%associations that are part of F2 and F8. Moreover in F3, the
%\emph{De\_activateABS ExecFrame} provides a \emph{Service} (i.e.,
%\emph{TurnABSoff}) that is required by the \emph{De\_ActivateACC ExecFrame}, and
%the two \emph{ExecFrames} require a common \emph{Service} (i.e.,
%\emph{TurnACCoff}).

%
% Relationships between these features are defined by the propositional formula
% $\Phi = $  \rs{refer to fig and illustrate}
 
 
% \rs{Adapt next paragraph:}
% In this example, domain model elements are state machine constructs such as
% states, transitions, state entry and exit activities, and transition actions.
% The presence conditions are given in boxes next to the corresponding domain
% model elements, e.g., the state \name{{Waiting}} in Fig.~\ref{fig:wash} is
% annotated by the presence condition \feat{Heat}$\vee$\feat{Delay}.
% Feature \feat{Wash} is mandatory and thus always occurs.  For simplicity
% of presentation, we omit \feat{Wash} from the presence conditions.  We
% also do not annotate elements whose
%  presence conditions are \emph{true}, e.g., the state \name{{Locking}}.
% 
% \BD[Feature Configuration] \label{def:featconfig}
% A \emph{valid feature configuration} $\rho$ of a product line $P$ is a subset of
% its features that satisfies $\Phi_P$, i.e., $\Phi_P$ evaluates to \emph{true}
% when each variable $f$ of $\Phi_P$ is substituted by \emph{true} when $f \in
% \rho$ and by \emph{false} otherwise. The set of all valid configurations in $P$
% is denoted by $\mathsf{Conf}(P)$.
% \ED
% \BD[Product Derivation]
% A product $M$ is \emph{derived from} the product line $P$ under the feature
% configuration $\rho$ if $M$ contains those and only those elements from the
% domain model whose presence conditions are satisfied for the features in $\rho$.
% \ED
% 
% \rs{The next paragraph is a stand-in using a different example. It will be
% changed to describe the actual example (see attached document):}
% For the example in Fig.~\ref{fig:wash},  sets \{\feat{Wash}, \feat{Heat},
% \feat{Dry}\}, \{\feat{Wash}, \feat{Dry}\} and \{\feat{Wash}\} are some of the
% valid configurations of the product line $W$.  Any set not containing the
% feature \feat{Wash} or containing both \feat{Heat} and \feat{Delay} does not
% correspond to a valid configuration as it violates the formula $\Phi_W$ given
% above.  The product derived using only the feature \feat{Wash}  will go through
% the states \name{{Locking}}, \name{{Washing}} and  \name{{Unlocking}}, while the
% product derived using the features \feat{Wash} and \feat{Dry} will go through
% the states \name{{Locking}}, \name{{Washing}}, \name{{Drying}} and
% \name{{Unlocking}}.
% 
% 
% Note that while our work is based on the above definition of annotative product
% lines it can readily be adapted to other annotative approaches, e.g.,
% CVL~\cite{haugen12}.  
  
  
  
  
%- What SPL aspects did WE model.\\
%- How did we create the model in the paper: ``GM uses SPL, but due to
%  non-disclosure, we present a model that is reasonable, but also validated that
%  it is realistic in terms of its parameters (size, number of features, number
%  of variation points, etc)''





% \subsection{Transforming GM Product Lines}
% 
% 
% - What does it take to build the tool and -if necessary- whether there were any
%   changes to the VCS-to-Autosar transformation itself that needed to be made 
% 
% 
% This section should also describe the industrial requirements for transforming
% product lines in GM: scalability, correctness.
% 
% We demonstrate scalability through our case study.
% We guarantee correctness analytically: correctness of lifting and property
% preservation by DSLTrans.
